I don't understand why this works and how it fixes the issue.
The LookAheadMacroDefinition are inserted for all macro definitions, regardless of whether it's macro or macro_rules, and nothing is done for use items.
The reversed rib walk in fn apply_pattern_bindings can also encounter arbitrary ribs before encountering a LookAheadMacroDefinition.

Also "shallow" -> "shadow" in the PR/commit messages and file names.

The reversed rib walk in fn apply_pattern_bindings can also encounter arbitrary ribs before encountering a LookAheadMacroDefinition.

There may be a bug if LookAheadMacroDefinition fails to apply correctly.

I don't understand why this works and how it fixes the issue.

LookAheadMacroDefinition stores the macro expansion result and serves as a fallback in resolve_ident_in_lexical_scope, ensuring it takes the correct resolution path:

@rustbot ready

@bvanjoi
Are you sure this cannot successfully resolve some names that should not be resolved?
(I started reviewing yesterday, but it was late so I'll finish today or on Monday.)

Are you sure this cannot successfully resolve some names that should not be resolved?

I need to test this with additional cases across different rib contexts. @rustbot author

Reminder, once the PR becomes ready for a review, use @rustbot ready.

Should we introduce this change as a lint instead?

We'll definitely need a crater run and possibly a lint in the end.

But at this point we probably rather need some more or less formal model of the rules that we want to achieve.
At both call site (including code coming from the macro itself) and at def site local variables and items can interleave, so it needs to be clarified what are the priorities.
I.e. what is the search order here.

#![allow(unused)]

fn f() {
    let a = 0;
    {
        fn a() {}
        {
            let a = 0;
            {
                fn a() {}
                
                #[macro_export]
                macro_rules! mac {
                    () => {
                        let a = 0;
                        {
                            fn a() {}
                            {
                                let a = 0;
                                {
                                    a; // use
                                }
                            }
                        }
                    };
                }
            }
        }
    }
}

fn main() {
    let a = 0;
    {
        fn a() {}
        {
            let a = 0;
            {
                mac!();
            }
        }
    }
}

But at this point we probably rather need some more or less formal model of the rules that we want to achieve.

Have there been any mathematical models proposed, such as proof trees in type theory, to formally describe macro expansion? I've never encountered.😂

@bvanjoi
https://www-old.cs.utah.edu/plt/scope-sets
That's what macros 2.0 hygiene is inspired by as well.

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

what is the search order here.

I will try to answer this after reading this book.

@rustbot ready

Let's benchmark this to understand the costs.
@bors2 try @rust-timer queue

Another high level alternative to this is to just report errors for everything that cannot be resolved correctly using some single pass algorithm similar to what was used before.
It may just be too costly to implement proper def-site hygiene for local variables.

☀️ Try build successful (CI)
Build commit: 47ce876 (47ce876df58648fb78e86c74948d24c6476569a4, parent: f6df223ea8c0017e64ce19c99afa32c0c629142c)

Finished benchmarking commit (47ce876): comparison URL.

Overall result: ❌ regressions - BENCHMARK(S) FAILED

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

❗ ❗ ❗ ❗ ❗
Warning ⚠️: The following benchmark(s) failed to build:

• runtime:css

❗ ❗ ❗ ❗ ❗

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

Max RSS (memory usage)

Cycles

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 467.107s -> 468.456s (0.29%)
Artifact size: 388.34 MiB -> 388.37 MiB (0.01%)

Yeah, the current approach (or at least the current implementation) is not going to fly.